Refactor DC Outer Loops creation #1158
Conversation
Signed-off-by: vmouradian <[email protected]>
Signed-off-by: vmouradian <[email protected]>
Signed-off-by: vmouradian <[email protected]>
Signed-off-by: vmouradian <[email protected]>
vmouradian
changed the title
Signed-off-by: vmouradian <[email protected]>
|
Support of OuterLoopNames parameters for DC is in this separated PR : #1159. |
| // remove area interchange control outer loop if no area in the network, active power will be distributed with classical slack distribution | ||
| boolean areaInterchangeControl = outerLoops.stream().anyMatch(DcAreaInterchangeControlOuterLoop.class::isInstance); | ||
| if (!network.hasArea()) { | ||
| outerLoops.removeIf(DcAreaInterchangeControlOuterLoop.class::isInstance); |
There was a problem hiding this comment.
don't remove the outerloop here.
the outerloop should handle the 'no area' situation by itself.
There was a problem hiding this comment.
This was done to reproduce the behavior of DC slack distribution (which is done before equations solving and not via an outerloop).
So in the existing implementation of the AIC outreloops in the "no area" case :
- The AC one defaults to distributed slack outerloop
- The DC one does not handles the case because it should be handled by the DC LF engine (distribute slack before the other computations)
This is something that can be homogenized but I think it will be out of the scope of this refactoring
| implements OuterLoop<V, E, P, C, O>, ActivePowerDistributionOuterLoop<V, E, P, C, O> { | ||
| implements ActivePowerDistributionOuterLoop<V, E, P, C, O> { |
There was a problem hiding this comment.
since AbstractActivePowerDistributionOuterLoop implements ActivePowerDistributionOuterLoop, this part is redundant and can be removed too
implements ActivePowerDistributionOuterLoop<V, E, P, C, O>There was a problem hiding this comment.
yes ! fixed in 929a5b8
| static List<DcOuterLoop> createDcOuterLoops(LoadFlowParameters parameters, OpenLoadFlowParameters parametersExt) { | ||
| List<DcOuterLoop> outerLoops = new ArrayList<>(); | ||
| if (parameters.isPhaseShifterRegulationOn()) { | ||
| DcIncrementalPhaseControlOuterLoop phaseShifterControlOuterLoop = new DcIncrementalPhaseControlOuterLoop(); |
There was a problem hiding this comment.
Hello, a small remark here, maybe a little bit out of the scope of this PR : when comparing with createAcOuterLoops, it shows that the parameter phaseShifterControlMode is not taken into account in DC mode. Maybe it should be mentioned in the doc (or even with a log message, because default value of this param is CONTINUOUS_WITH_DISCRETISATION and not INCREMENTAL)
Signed-off-by: vmouradian <[email protected]>
|
Please check if the PR fulfills these requirements
Does this PR already have an issue describing the problem?
Part of #1091 + adds consistency (imo)
What kind of change does this PR introduce?
Feature / refactor
What is the new behavior (if this is a feature change)?
DC Outerloops creation is made more consistent with AC ones (created in the OLF parameters class then are contained in DcLoadFlowParameters)
Support of
outerLoopNamesparameter for DC is in this separated PR : #1159.Does this PR introduce a breaking change or deprecate an API?